Not Applicable
Not Applicable
Not Applicable
(1) Field of the Invention
The present invention relates to a repository which stores properties of database objects and in particular to a metadata repository for a relational database.
(2) Description of Related Art
Relational databases generally comprise of two main portions, namely an informational database which stores data in the form of objects, and a metadata repository which stores information concerning the properties of the objects.
Thus, for example, in Oracle""s Discoverer database, the metadata defining the properties of objects stored within the database are contained within the EUL (End User Layer) of the database.
This system allows the data stored in the informational database to be updated, whilst the properties of the data can be maintained separately in the repository.
Typically, the properties of the database objects are stored in the metadata repository in the form of object tables. In general, each object table defines the properties of a respective type of object contained within the database, with each row in the table defining the properties for a specific object.
Thus for example, xe2x80x9cFolderxe2x80x9d objects contained within the database would have a corresponding xe2x80x9cFolderxe2x80x9d table within the metadata repository. The folder table defines the properties of all of the xe2x80x9cFolderxe2x80x9d objects, with the properties of each object being set out on a respective row of the table. A typical example of such an object table is shown in FIG. 1 and will be described in more detail below.
The structure of both the informational database and the metadata repository, are determined by the database designers. The tables used in the metadata repository have a fixed structure which allows a limited number of properties to be defined, as envisaged by the database designers.
Typically, relational databases are provided centrally for a number of different clients. In this case, the properties of the objects are initially set by the database operators.
However, it is common for different clients using the database to want to add in additional properties for certain database objects. Currently, this can only be achieved by having each respective user define their own property information in an alternative data store, separate from the repository.
In this case, the additional property information, which for example could be stored on the user""s own personal computer, must then be referenced back to the respective object in the repository.
However, there are a number of disadvantages to this technique. Firstly, there is no longer a single source of truth for the properties of the database objects. This means, that should the properties of the object need to be referred to, then it is necessary to check both the repository and the separate data store to ensure all the property data is retrieved.
Secondly, there is no integrity between the separate data sources. Accordingly, if the element is removed from the original repository there is no effect on the additional information provided in the secondary data store.
Thirdly, transferring or duplicating the repository requires having separate processes for moving the additional property information. Thus, if the additional property information is to be provided to an alternative user, it must be copied from the original user""s processing system and onto the additional user""s processing system.
As an alternative, repositories can utilise a fixed set of attributes for client extensions. This allows clients to define a limited number of properties for each object. However, because of the use of the fixed table structures within the repository, this has the disadvantage that there is a limit to the number of extended attributes and there is a limit to the size of any individual extended attributes, thereby limiting the properties that can be defined.
In accordance with the present invention, we provide a repository which stores properties of database objects, the repository including:
a. a first store for storing a number of predetermined properties;
b. a second store for storing additional properties; and,
c. a processor coupled to the first and second stores for determining or modifying the properties stored in the first and second stores for at least one of the database objects.
Accordingly, the present invention provides a repository which stores properties of database objects. The repository includes a first store for storing predetermined properties and a second store for storing additional properties. With both the first and second stores being provided within the repository, a processor can be used for accessing or modifying the properties within both stores simultaneously. This ensures that a single source of truth is provided for all the properties of the database objects, with integrity being maintained between the properties stored in the first and second store. Furthermore, by providing both first and second stores centrally within the repository, this overcomes the need for additional information to be located at a user""s remote location, thereby ensuring that the property information is available to all users of the database.
Typically the first store comprises a fixed table structure, the predetermined properties of each object being stored in the respective portion of the fixed table structure. The properties of each object are generally stored in a respective row of the fixed table structure, with each property being stored in a respective column. In this case, each table generally relates to a different type of object with the properties of each object of the given type being stored in a respective row. However, alternative table structures may be provided. Thus, for example each table could include details of multiple types of object, or details of separate objects individually. Alternatively, the elements could be arranged in columns with the properties arranged in the rows of the table.
Typically, the second store comprises a segmented table structure, the additional properties of each object being stored in one or more respective portions of the segmented table structure. By using a segmented table structure, this allows a number of rows to be assigned to a given object (or element). This ensures that any number of properties can be stored for a given object thereby vastly increasing the versatility of the repository system.
Typically the additional properties of each object are provided as an XML file. This provides a simple way of allowing a user, or an operator of the database system, to define additional properties for objects within the database. The nature of XML files means that there is no limit to the number of additional properties that can be defined. Alternative techniques could however be used, such as the use of a simple text file or another SGML file format. However, the use of an XML file is particularly advantageous as it allows the elements, and attributes of the XML schema to be used to define the properties of the data.
Typically the XML file is divided into one or more segments which each segment being stored in a respective row of the segmented table structure. This allows the segmented table to store a limited number of characters in each row whilst still accommodating the entirety of the XML file, thereby ensuring that all the properties of the respective object are stored. However, the table may be modified to include an additional number of columns, for example with different portions of the XML file being stored in different columns.
The processor is usually adapted to extract the additional properties from the second data store by extracting and recombining the segments of the XML file. Once the XML file has been recombined, this allows the processor to determine the properties of the object contained within the database. However, any suitable system, such as extracting portions of text from the table may also be used.
Typically the properties are stored as name-value pairs. In this case, the name of the name-value pair represents the particular property under consideration, whilst the value represents the particular value of the property. However, the properties may be stored in any appropriate format depending on the type of property being defined.
Typically the repository is adapted to be coupled to at least one end station. In this case, the processor is usually adapted to provide the properties of at least one database object in response to a request from the end station. This allows remote users who are accessing the database from a remote location to obtain details of the properties of the objects from the repository, with the processor ensuring that the user obtains properties from both the first and second store in response to a single request.
It will be realised from this that the processing operations required to generate a query and then obtain a result can be split between the processor at the end station and the processor at the repository. In particular, the processor at the end station can generate the query, causing the repository processor to retrieve the results. Alternatively, the query could also be generated by the repository processor in response to input commands.
The repository is usually adapted to couple to at least one end station via a communications network. This allows remote users to access the database, for example, by the Internet.
The present invention also provides a relational database system for providing information regarding the database objects. The system typically includes a database for storing the database objects, the database being coupled to a repository according to the present invention.
In this case, the relational database system usually further comprises a number of end stations coupled to the database and the repository via a communications network. In this case, the database and the repository are responsive to request from the end stations to provide information regarding the database objects. Alternatively however the database can be a stand alone database.